home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20000824-20010305
/
000099_news@columbia.edu _Wed Oct 25 18:39:56 2000.msg
< prev
next >
Wrap
Internet Message Format
|
2001-03-05
|
7KB
Return-Path: <news@columbia.edu>
Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
by fozimane.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA17891
for <kermit.misc@cpunix.cc.columbia.edu>; Wed, 25 Oct 2000 18:39:56 -0400 (EDT)
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id SAA11923
for <kermit.misc@watsun.cc.columbia.edu>; Wed, 25 Oct 2000 18:39:56 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id SAA23392
for kermit.misc@watsun.cc.columbia.edu; Wed, 25 Oct 2000 18:38:27 -0400 (EDT)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: Luiz Geraldo Silva Braz <braz@i2.com.br>
Subject: Re: log of a kermit comunication
Date: Wed, 25 Oct 2000 20:34:21 -0200
Organization: POP-MG
Message-ID: <Pine.LNX.3.96.1001025195005.17762B-100000@atlanta.i2.com.br>
To: kermit.misc@columbia.edu
OK. This is not a kermit conversation. :-)
But I supose that this software was built by someone that
has based in kermit to do his work.
Analizing many logs I have recorded I supose that probably
this (not kermit but) kermit-like implementation uses 3
character of checksum.
And more: If I discover how they have calculated their kermit-like
checksum I solve my problem. And my job. :-)
I know that kermit especification suport a there character
checksum based in crc-16. Althougth the paper I have read it didn't
mention clearly how I should calculate the 3 checksum character
of the packet.
Where could I get a complete description of kermit that include
the 3-character checksum calculation?
I am suposing that the correct algoritm is something like
the lines above.
LD = length of data
LC = length of Checksum (three in this case)
TL = LD + LC + 2 (2 because of the sequetial
and packet type characters)
TL32 = TL + 32 (Total length excess-32)
S = Sequencial number of the packet
S32 = S + 32
T = caracter that represents the type of packet
D = data to be transmited
unsigned short int CRC = crc16(concat(TL32,S32,T,D))
C1 = (CRC shr 12) and $0F (1st. character)
C2 = (CRC shr 6) and $3F (2nd. character)
C3 = CRC and $3f (guess you)
Is it the method?
Thanks in advance.
Luiz Braz
braz@i2.com.br
On 25 Oct 2000, Frank da Cruz wrote:
> In article <Pine.LNX.3.96.1001024185713.5485B-100000@atlanta.i2.com.br>,
> Luiz Geraldo Silva Braz <braz@i2.com.br> wrote:
> :
> : This is a log of kermit comunication that I need to decode.
> : The big questions are:
> :
> : 1) What king of command could generate the first string
> : sent to the kermit server?
> :
> : #A& D#C"@%<ENTER> (see the log above)
> :
> : 2) Would this entire comunication be the result of just
> : one c-kermit command or a lot of commands?
> : What would be this (these) commands?
> :
> : I intend to create a script (using expect) to interact
> : with c-kermit and automate this kind of comunication.
> :
> : I have inserted some coments (***) inside the log.
> :
> : Each set of packets has the sender ID ( "1>" to client and "0>"
> : to the server) and two representations of the data sent in 2
> : columns.
> :
> : Some non-printbles caracteres are represented by "." at the
> : rigth column. In the left column appears the Hex code of each
> : char and the simbol of the non-printblesi char.
> :
> : Thanks in advance.
> :
> : Luiz Braz
> : braz@i2.com.br
> : PS: Sorry about the errors. This is the first message I have
> : wroten in English. :-)
> :
> : >-------------------------------------------------------------------------
> : *** Estabilishing the connection. 817371001 is just the phone number. :-)
> : 1> 0000: 41 54 44 54 30 77 30 33 31 38 31 37 33 37 31 30 ATDT0318173710
> : A T D T 0 w 0 3 1 8 1 7 3 7 1 0
> : 0010: 30 31 0D 01.
> : 0 1 ^M
> :
> : 0> 0000: 0D 0A 43 4F 4E 4E 45 43 54 20 39 36 30 30 2F 41 ..CONNECT 9600/A
> : ^M ^J C O N N E C T bs 9 6 0 0 / A
> : 0010: 52 51 2F 56 33 32 2F 4C 41 50 4D 2F 56 34 32 42 RQ/V32/LAPM/V42B
> : R Q / V 3 2 / L A P M / V 4 2 B
> : 0020: 49 53 0D 0A IS..
> : I S ^M ^J
> :
> This is the CONNECT message from the modem.
>
> : 1> 0013: 23 41 26 20 20 44 23 43 22 40 25 0D #A& D#C"@%.
> : # A & bs bs D # C " @ % ^M
> :
> The format of a Kermit packet is:
>
> MARK LEN SEQ TYPE DATA CHECK
>
> Where:
>
> MARK is a control character, Ctrl-A by default.
> LEN is a one-byte excess-32 length field.
> SEQ is a one-byte excess-32 sequence number.
> TYPE is a one-byte packet type.
> DATA is 0 or more bytes of data.
> CHECK is the block check.
>
> Let's assume that your protocol dump is printing Ctrl-A as "#A". In
> that case:
>
> LEN = '&' = ASCII 38 - 32 = 6.
> SEQ = ' ' = ASCII 32 = 32 = 0.
> TYPE = ' ' which is not a valid Kermit packet type.
> DATA = D#C"@
> CHECK = %
>
> So the MARK is wrong, the LEN is wrong, and the TYPE is wrong. No Kermit
> program would recognize this as a valid packet.
>
> If, however, the two spaces are a mistake of your recording tool, and really
> there is only one space, then we have:
>
> LEN = '&' = ASCII 38 - 32 = 6.
> SEQ = ' ' = ASCII 32 = 32 = 0.
> TYPE = 'D' (Data)
> DATA = #C"@
> CHECK = %
>
> It's closer, but still the length is wrong (6 instead of 7). But if we
> assume that #A is really Ctrl-A, then maybe #C really is Ctrl-C, in which
> case the length would be correct. But the block check is still wrong.
>
> : *** The server answers with an ack packet (Y) and a unknown M-package.
> : What kind of package is it? I did't see it at the kermit
> : protocol description I have?
> : 0> 0024: 23 41 25 20 20 59 2A 24 33 0D 23 41 53 20 5F 4D #A% Y*$3.#AS _M
> : # A % bs bs Y * $ 3 ^M # A S bs _ M
> :
> This too has a superficial resemblence to a Kermit packet, if we assume that
> #A really is Ctrl-A and the two blanks are really one blank:
>
> LEN = '%' = ASCII 37 - 32 = 5.
> SEQ = ' ' = ASCII 32 = 32 = 0.
> TYPE = 'Y' (ACK)
> DATA+CHECK = *$#
>
> But the block check isn't right, no matter how you interpret it.
>
> [ ... and so on ... ]
>
> : and the result of the command continues to come in sequences
> : of three packages... (see the big questions I have made at the
> : begining of this mesage.)
> :
> There is some resemblence to Kermit protocol, but it isn't really Kermit
> protocol. The proper sequence of messages is not there, the packets are not
> in the right format, the block checks are not correct. And this is even
> allowing for some aftereffects of your recording tools.
>
> - Frank
>
>